Many systems and products incorporate programmable parts, such as FPGAs, PLDs, EEPROMS and microprocessors. Often, the programming for these parts changes during the development stage, prototyping stage and even into the production stage. It is important and yet difficult to incorporate the latest programming into the parts at each stage, particularly in the advanced manufacturing stages when several entities may be involved.
In the manufacturing stage, for example, an outside contract vendor may program these parts for systems and products designed by the originating company; a contract manufacturer may perform the actual integrations of the parts within the systems and products, for sale under label of the originating company. The difficulties occur when the originating company identifies technical issues with firmware that must be changed and incorporated into the integration and/or manufacturing processes. The firmware changes must be communicated first to the contract vendor, and then physically integrated as a change into the parts integrations.
Implementing programming changes from the originating company and the contract vendor and manufacturer is thus tedious and difficult; and yet any delay in programming parts within these products and systems can cause critical program problems for the originating company. Likewise, an incorrect programming of parts with firmware that is not the latest revision can also cause critical program problems; systems and products may become inoperable in such instances.
There are two general methods for updating programming to programmable parts within such systems and products, and according to the prior art:
1. New program revisions are sent from the originating company to the contracting vendor. The vendor programs a few parts and sends them back to the originating company for verification. Once verified, the contract vendor is authorized to program the parts in larger quantities; the contract vendor then ships parts to the contract manufacturer, where programmed parts with older revisions are purged and the newer revision parts are integrated within the processes.
This method has several drawbacks. First, changes according to this method can take several weeks. Second, there is often considerable confusion about which revision should be implemented into the systems or products. Third, each company—the originating company, the contract vendor, and the contract manufacturer—typically expends significant overhead and resources in implementing and verifying the method. And fourth, manufacturing costs significantly increase when large quantities of programmed parts are purged to prepare for new revisions of these parts.
2. Parts are programmed in In-Circuit Test (ICT) An ICT generally consists of a “bed of nails” configuration to access signals on a circuit board. An ICT can be used to test boards, or components, but it may also be used to program parts. For example, certain pin configurations to a programmable part may be used to program the part; while other pin configurations to the programmable part may be used to test the part. There are several difficulties with the ICT: First, a long development time usually results from constructing an ICT. Second, the typical ICT cannot operate at high speeds, lengthening the time to program the part. Third, the use of an ICT is not generally scaleable to program many parts; the ICT then may become a bottleneck to efficient manufacturing and inventories.
It is, accordingly, one object of the invention to provide methods for programming of parts through a network. Other objects of the invention are apparent within the description that follows.